每個Graph可以看做是C#中的型別，所以在設計上通常不會一個型別囊括全部的功能，再者資料的多元性也非一建構而成，而是逐步的增改而形成的。因此在單一Graph中的功能最好不要太過複雜，遵循型別的設計概念來看，要分出多個型別（也就是多個Graph）來處理。

而在現今為止所構思的使用情境皆可說是極盡所能的避開了複雜的直實使用狀況，像是在實際的開發中，有可能會對應企劃所給予的文字資料（角色扮演裡的任務對話）而利用TextMesh Pro進行字型Sprite生成，或是進行AssetBundle又或是Addressable打包的步驟。

秉持這樣設計所得到多個Graph，就必須要有個機制可以將Graph串連起來。其它的視覺化工具如PlayMaker等都可有一個節點是可以啓動另一個Graph（不同的擴充中其名詞不同），可猜想到的，陽春的AssetGraph（AG）並沒有此節點，所幸在詳閱其使用文件後，還是可以看到它提供了AssetGraphUtility，仍可以由它處的Editor Script呼叫所提供的API進行Graph串連。

不過，如同IAssetGenerator等API文整個是找不到的狀態，這次的串連又要費勁的自行嘗試，更讓人頭疼的，這次連可以參考的內部引用都沒有，只能硬著頭皮不停的去試，看是否可以在一定的時間內完成拚裝的任務。

只好花些時間讀提供的程式碼，並依據不同的情況去試。其中，利用BatchBuildConfig進行產生的方式很有趣，好像是先行組合好後，再利用名稱直接進行執行。而利用Guid（AssetDatabase回傳的，不是System定義的），則可以設定其執行順序，數字小者為先。

今日測試用的專案放罝在Git Repo中的multiple-asset-graph目錄裡，嘗試花了一些時間，但結果還算是不錯。

和我記憶中的另一擴充進行比較

AG出現的時間點恰巧是在uTomate（UT）不再進行更行後。UT可謂第一款在Unity Editor以視覺化方式處理著

• 生成Prefab
• 生成Scene
• 滙出、滙入package
• 打包Asset Bundle

簡單來說AG在達到最終形態前會越加趨近於uTomate。它們本質上都是要將Editor中的處理從撰寫程式的方式以節點方式進行擴增。

若不論AssetBundle和近幾版才加入的Addressable，UT在數年前所提供的節點功能已是AG數倍之多，然UT畢竟不是Unity自家的產物，在無法取得、調整Unity Editor底層程式碼的情況下，有些UT的Bug一直到Ancient Light Studios（其開發團隊）下架UT都無法解決。

雖然UT在多數方面表現的比AG好，但它也不乏有多數需要改進的部份。可惜，這一切都是後話了。在UT的年代裡Unity生態中對於視覺化工具的需求並不高，那時用PlayMaker的開發者可說是異類，更遑論只能用於Editor中的視覺化工具。早些年Editor環境中唯程式設計師有能力經手。不考慮由非程式人員處理的情況下，Editor中用視覺化工具來完成建置、生成等流程對多數的程式人員來說無疑是多此一舉。

時間飛逝，數個年頭過去了，不但遊戲端製作多數的工具都有視覺化的對應，連Editor也朝著這方面前進。依照往常Unity納賢的想法，若是能夠結合Ancient Light Studios這份助力，相信AG必定有長足的進步。

寫到這裡，突然想到尚未對Unity目前生態中的視覺化工具做過介紹，就一頭栽進了AG的研究中。接下來會用一篇簡敍Unity現有的擴充，不論是自家的或是第三方的視覺工具，讓有興趣了解、探索的開發者也可以平行的展開了解，也可以在討論區交流或是給予建議。

而於簡述後，會正式的進入Bolt的世界中。至於AG另一打包的功能由於Unity現今已開始推廣Addressable的使用

• Addressable Asset System
• Addressable Asset System全新资源管理流程

但AG中對於Addressable的支援還很初期，且目前的使用情境過於簡單不能展現期優勢，之後會另行安排討論Addressable的篇章。